A developer will typically test product code before it is released. In one approach, the developer may devise a collection of unit tests to perform on the product code. Each unit test investigates the behavior of a particular part of the product code. The unit tests preferably provide dependable conclusions that can be reliably reproduced. However, product code often makes reference to functionality “outside” the control of the product code. For example, product code can make reference to a file system, system clock, network resource, etc. In each of these cases, the product code itself cannot ensure that the referenced functionality will operate in a deterministic manner. This makes the developer's unit tests potentially unreliable, essentially rendering them, at least in part, integration tests. Integration tests are not isolated from the potential non-determinism of the execution environment.
Some languages and associated execution systems allow a developer to dynamically redefine methods during execution of the product code. This technique presents one way to eliminate dependency on potentially non-deterministic environments. However, other languages and associated execution systems provide static checking and static binding. The programming languages that run on the .NET® framework are examples of such languages. The static checking and binding prevent methods from being redefined at runtime in the direct manner of, for example, JavaScript®.